Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-tn3270e-practices-00.txt < prev next >

Wrap

Text File | 1993-08-18 | 19.4 KB | 526 lines

TN3270 Enhancements Working Group Jon Penner Internet Draft August 1993 TN3270 Current Practices Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This document describes the existing implementation of transferring 3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270. Information is provided to aid in the implementation of TN3270 servers as well as client terminal emulators. The following areas pertaining to TN3270 implementations are covered in this document: 1. the telnet options negotiated to transition from a NVT ASCII state to a TN3270 state ready to process incoming 3270 data stream commands 2. the method for sending and receiving 3270 data 3. the method of handling some special keys known as SYSREQ and ATTN using current available telnet commands. 4. the events that will transition a TN3270 session back to an NVT session Motivation 3270 display terminal data differs from traditional display terminal data in that it is block mode and uses EBCDIC instead of ASCII character representation. These two differences are the primary J. Penner Expires February 1994 [Page 1] TN3270 Enhancements Working Group Jon Penner Internet Draft August 1993 reason for the differentiation of TN3270 from standard Telnet in this document. Background Existing proprietary IBM networks are not easily integrated with the increasing number of multi-platform networking environments, specifically TCP/IP. These proprietary IBM networks are referred to as SNA (Systems Network Architecture) in this document. To address this issue, several vendors have introduced telnet servers that provide a TCP/IP users a connection to existing IBM mainframes by supporting display terminal emulation using a subset of the existing telnet protocol. IBM now also offers host based tn3270 support over TCP/IP. IBM terminals are generically referred to as 3270's which includes a broad range of terminals and devices, not all of which actually begin with the numbers 327x. 3270 terminals in the IBM SNA network environment have 2 parallel sessions with the host computer. One is used for communicating with the host application, the other is used for communicating with the network control program that links the terminal with the appropriate host computer. For the purposes of TN3270, this distinction is not apparent or relevant since there is actually only a single telnet session with the host computer or server. On an IBM SNA network, the 3270 terminal has a special key that toggles between the two sessions (SYSREQ). A brief discussion on how some telnet servers deal with this is included. In an SNA environment, a client session is identified by a Logical Unit (LU) name. In a non-SNA environment, there is not a LU name associated with a client session. The closest thing to a LU name in the TN3270 environment is the client's IP address. Although some telnet servers are connected to the host using SNA, tn3270 clients using these servers have no defined way to determine the LU name associated with the session. Currently, support for 3270 terminal emulation over Telnet is accomplished by the de facto standard of negotiating three separate Telnet Options - Terminal-Type [2], Binary Transmission [3], and End of Record [4]. This negotiation and the resulting data flow will be described below. RFC 1041 [1] attempted to standardize the method of negotiating 3270 terminal support by defining the 3270 Regime Telnet Option. Historically, very few developers and vendors ever implemented RFC 1041. All references in this document to the 3270 datastream, SNA versus non-SNA operation, 3270 datastream commands, orders, structured J. Penner Expires February 1994 [Page 2] TN3270 Enhancements Working Group Jon Penner Internet Draft August 1993 fields and the like rely on [6]. References to SNA Request and Response Units rely on [7]. TN3270 does not support typical SNA responses and is classified as a non-SNA protocol. A TN3270 emulator is not aware or concerned about how the telnet server is connected to a 3270 host application. Current telnet server implementations are either 3270 host based or connected to the host using the SNA protocol. NOTE: Except where otherwise stated, this document does not distinguish between telnet servers that represent SNA devices and those that represent non-SNA 3270 devices. Some typical "SNA" functions such as the SYSREQ and ATTN keys have been mapped to existing telnet function codes and are supported by some telnet server implementations. There are several shortcomings in current tn3270 implementations; among them are the following: - It provides no capability for Telnet clients to emulate the 328x class of printers. - There is no mechanism by which a Telnet client can request that a connection be associated with a given 3270 device-name. This can be of importance when a terminal session is being established, since many host applications behave differently depending on the network name of the terminal. In the case of printer emulation, this capability is an absolute necessity because a large number of host applications have some method of pre-defining printer destinations. - The 3270 ATTN and SYSREQ keys are not universally supported. - There is no support for the SNA positive/negative response process. All data that is sent is assumed to either be handled or ignored. A negative response indicates some sort of error at the client while processing the previously received data; this could be caused by the host application building a 3270 datastream that contains an invalid command, or by a mechanical error at the client side, among other things. Positive responses indicate processing of the previously received data has completed. - There is no mechanism by which the client can access the SNA BIND information. The BIND image in a SNA environment contains a detailed description of the session between the telnet server and the host application. - The connection negotiation does not make it clear whether clients J. Penner Expires February 1994 [Page 3] TN3270 Enhancements Working Group Jon Penner Internet Draft August 1993 should support 3270 structured fields. These and other issues are addressed by the Internet-Draft [?] written by Bill Kelly Command Names and Codes TN3270 makes use of existing Telnet commands and codes and does not define any new commands. BINARY 0 TERMINAL-TYPE 24 EOR 25 Additional commands may be used during a TN3270 session and are interpreted as per their respective RFCs. Examples of this are 3270-REGIME, SUPPRESS-GO-AHEAD, and TM. Command Meanings See respective RFCs. Connection Negotiation The following example shows a TN3270-capable server and a tn3270 client establishing a connection: The TCP/IP port generally used to connect with is 23 (Telnet). At any place before and during the tn3270 connection negotiation process, other telnet commands and data may be transferred and will be interpreted under the existing telnet state. Some existing tn3270 servers start a client connection using an NVT telnet dialog to establish parameters needed to complete the tn3270 connection to the desired host. The order of negotiating terminal type, EOR and BINARY is not significant, this example shows a typical tn3270 connection. Server: IAC DO TERMINAL-TYPE Client: IAC WILL TERMINAL-TYPE Server: IAC SB TERMINAL-TYPE SEND IAC SE Client: IAC SB TERMINAL-TYPE IS <terminal type>IAC SE J. Penner Expires February 1994 [Page 4] TN3270 Enhancements Working Group Jon Penner Internet Draft August 1993 where <terminal type> is a string consisting of terminal model, type and support of enhanced attribute bytes; and example is IBM-3278-2. The acceptable values are listed in RFC 1340, Assigned Numbers [5]. Other values are in use that do not exist in [5]. The -2 following 3278 designates the alternate screen size. 3270 terminals have the ablity to switch between the standard (24x80) screen size and an alternate screen size. Model -2 is 24x80 which is the same as the standard size. Model -3 is 32x80, model -4 is 43x80 and model -5 is 27x132. Appending the two character string "-E" to the end of the terminal type signifies that the terminal is capable of handling 3270 extended data stream. This is interpreted to mean that the terminal is able to handle structured fields, which are described below. Some telnet server implementations also interpret this to mean that the terminal is capable of handling extended attributes (highlighting, field validation, character set, outlining, etc.) [6]. The 3279 series of terminals is capable of extended attributes while the 3278 series is not. Server: IAC DO EOR IAC WILL EOR Client: IAC WILL EOR IAC DO EOR Server: IAC DO BINARY IAC WILL BINARY Client: IAC WILL BINARY IAC DO BINARY Server: <3270 data stream> Client: <3270 data stream> . . . . To terminate the connection the socket is closed by one of the session partners. Typically, when the user logs off of the host, the telnet server closes the connection. If the telnet server wishes to go back to NVT mode, it may issue the following commands: Server: IAC WONT BINARY Client: IAC DONT BINARY or Server: IAC WONT EOR Client: IAC DONT EOR Either one of the above two cases causes the connection to not satisfy the requirements for a valid TN3270 session. The telnet client should then process data from the server as though it were NVT ASCII data. J. Penner Expires February 1994 [Page 5] TN3270 Enhancements Working Group Jon Penner Internet Draft August 1993 Handling 3270 data The 3270 data stream consists of a command and its associated data. Commands include but are not limited to erase screen, erase and write to screen and read current screen; see [6] for a complete description of 3270 commands and parameters. The reason for negotiating the EOR telnet option [4] is to provide a method for separating these commands since no length information is specified. 3270 commands are interpreted by the telnet client in their entirety. Each 3270 command and possible data is terminated with the IAC EOR sequence. The Binary option [3] is also required since 3270 data may contain the FF (hexadecimal) or IAC character. When this character is encountered during a tn3270 connection it is handled as per the Binary RFC [3]. 3270 Structured Fields 3270 structured fields provide a much wider range of features than "old-style" 3270 data, such as support for graphics, partitions and IPDS printer datastreams. A structured field is a 3270 data type that allows non 3270 data to be embedded within 3270 data. Briefly, a structured field consists of the structured field command followed by one or more data blocks. Each data block has a length and a structured field identifier, followed optionally by additional data. Not every TN3270 client can be expected to support all structured field functions. There must be a mechanism by which those clients that are capable of supporting some or all structured field functions can indicate their wishes. This is typically done by adding "-E" to the end of the terminal type string. That is, when the terminal identifies itself as being able to handle extended attributes, it also is capable of being able to send and receive structured fields. The design of 3270 structured fields provides a convenient means to convey the level of support (including no support) for the various structured field functions. This mechanism is the Read Partition Query command, which is sent from the host application to the client. The client responds with a Query Reply, listing which, if any, structured field functions it supports. A TN3270 client that supports structured fields will respond to a Read Partition Query command with the appropriate reply. The sequence of events of when a client receives a Read Partition Query and it does not support structured fields is left up to the client implementation. Typically clients can identify at least this structured field and reply with a null set. J. Penner Expires February 1994 [Page 6] TN3270 Enhancements Working Group Jon Penner Internet Draft August 1993 Implementation Rules All commands and parameters are governed by their respective RFCs The 3270 ATTN (Attention) Key The 3270 ATTN key is interpreted by many host applications in an SNA environment as an indication that the user wishes to interrupt the execution of the current process. A majority of the telnet servers currently accept the telnet IAC BREAK (code 243) sequence to signal this event. Use of this key requires two things: - TN3270 clients should provide as part of their keyboard mapping a single key or a combination of keys that map to the 3270 ATTN key. When the user presses this key(s), the client should transmit a Telnet BREAK command to the server. - TN3270 servers should translate the BREAK command received from a TN3270 client into the appropriate form and pass it along to the host application as an ATTN key. In other words, the server representing an SLU in an SNA session should send a SIGNAL RU to the host application. The ATTN key is not supported in a non-SNA environment; therefore, a TN3270 server representing non-SNA 3270 devices should ignore any Telnet BREAK commands it receives from a client. The 3270 SYSREQ Key The 3270 SYSREQ key is useful in an environment where the telnet server is attached to the host using SNA. The SYSREQ key is useful in this environment when the host application becomes locked and the user wishes to terminate the session without closing the Telnet connection. The Telnet Interrupt Process (IP) command is interpreted by some telnet servers as a SYSREQ key. Other servers recognize the 3270 Test Request key as a SYSREQ key. In an SNA environment, pressing this key toggles the terminal between the host application session and the network control program session. Usually the user will enter LOGOFF once this key has been pressed to terminate the application session and then select a new host to connect to. Sometimes, if SYSREQ is pressed again, the host application will become unlocked and normal activities may then proceed. It is entirely up to the telnet server to interpret this command and send the appropriate commands to the host as well as format the resulting host data for display on the telnet client. The data J. Penner Expires February 1994 [Page 7] TN3270 Enhancements Working Group Jon Penner Internet Draft August 1993 format during the network control program session is in a slightly different format than normal 3270 data. Since the telnet server has no way to pass this data directly to the telnet client, it must either handle it entirely and ignore SYSREQ events or convert it to 3270 data to present to the client. There is no restriction that prevents the server from negotiating out of the TN3270 state to NVT to present this data. In order to implement SYSREQ key support, TN3270 clients should provide a key (or combination of keys) that is identified as mapping to the 3270 SYSREQ key. When the user presses this key(s), the client should either transmit a Telnet IP command or Test Request key to the server, depending on the server implementation. TN3270 servers representing non-SNA 3270 terminals may ignore any Telnet IP commands or Test Request keys they receive from a client. References [1] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, IBM Corporation, January 1988. [2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP Software, Inc., February 1989. [3] Postel, J., and J. Reynolds, "Telnet Binary Transmission", RFC 856, USC/Information Sciences Institute, May 1983. [4] Postel, J., "Telnet End of Record Option", RFC 885, USC/ Information Sciences Institute, December 1983. [5] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1340, USC/Information Sciences Institute, July 1992. [6] "3270 Information Display System - Data Stream Programmer's Reference", publication number GA23-0059, IBM Corporation. [7] "Systems Network Architecture - Formats", publication number GA27-3136, IBM Corporation. Author's Note Portions of this document were drawn from the following sources: - A White Paper written by Owen Reddecliffe, WRQ Corporation, October 1991. - Experimental work on the part of Cleve Graves and Michelle Angel, OpenConnect Systems, 1992 - 1993. J. Penner Expires February 1994 [Page 8] TN3270 Enhancements Working Group Jon Penner Internet Draft August 1993 - Discussions at the March 1993 IETF meeting. - Discussions on the "TN3270E" list, Spring 1993. - An Internet-draft written by Bill Kelly, Auburn University, July, 1993 Author's Address Jon Penner DCA, Inc. 2800 Oakmont Drive Austin, TX 78664 Phone: (512) 244-3871 Email: jjp@bscs.uucp J. Penner Expires February 1994 [Page 9]